Access check system utilizing cached access permissions

ABSTRACT

An access-check system for a network server comprises an access-cache for storing access-permissions generated by the server in response to resource access requests. The system retrieves the appropriate access-permission from the access-cache in response to receipt of a request necessitating the same access-permission as already generated for an earlier processed request. A user-token cache is also employed to assign a unique user-token, to be used in the access-cache, to each user logged on to the server. Changes made to the user-token cache are reflected in the access-cache by removing from the access-cache those entries containing the changed user-token. Changes made to an access control list are reflected in the access-cache by removing from the access-cache those entries containing the server resource with which the changed access control list is associated.

RELATED CASES

[0001] This is a continuation of application Ser. No. 08/689,838, filedAug. 14, 1996, which is hereby incorporated by reference.

FIELD OF THE INVENTION

[0002] The invention relates to the control of access by users toresources available on a server. In particular, the invention relates toa caching mechanism for more efficiently performing an access check inresponse to a current resource request that is similar to a previousrequest.

STATEMENT OF THE PROBLEM

[0003] In a computer network it is often desirable to control access byusers to resources available on the network. A user requesting aresource on a server may be local to the server or may be communicatingover a network with the server. A network includes local-area networks,intranet networks, and the internet as well as any other networkedcomputing environment. Requesting users might log on to the server witha unique user name and password or they might be ‘anonymous’ to theserver.

[0004] Anonymous users typically have limited access to the server'sresources. The occurrence of anonymous users is particularly prevalentin the case of networks such as the internet where any public user withinternet access can access a given server.

[0005] Access control lists are used to define the extent to whichdifferent users will be allowed access to different resources on aserver. An access control list contains information which allows theoperating system of a server to determine if a particular user has beengranted access rights for a particular resource requested by the user.Each restricted resource has associated with it an access control listwhich lists the users granted access to the resource. Depending on thelevel of access control implemented on a given server, access controllists might be associated with disks, with files, or with other storagevolumes. In an operating system where access control lists areassociated with disks, an access control list for a given disk definesthe access restrictions for all the resources or files stored on thatdisk. In an operating system where access control lists are associatedwith files, access by users is separately controlled for each file.

[0006] The flexibility and system performance offered by file-levelaccess control is significant. However, the number of access checksperformed by such a system is increased dramatically as compared to asystem where access control is maintained only at the disk level. Aswith all operations of an operating system, performing an access checkin response to a user request for a resource requires processing time ofthe central processing unit (“CPU time”). When a server is handling alarge number of file requests a significant amount of CPU time can beconsumed by performing the necessary access checks. In a systememploying file-level access control lists, the access control list ispart of each individual file-object. When a request for a givenfile-object is received, the operating system identifies the requestinguser, opens the requested file-object, reads the access control list todetermine if the user has the necessary access rights, and then deliversthe file-object to the requesting user if the user has the necessaryaccess privileges. Therefore it is necessary to open a requestedfile-object to perform the access check each time a file is requested.

[0007] The file-open operation consumes a great deal of CPU time. In aserver receiving frequent file requests, the need to open everyrequested file-object to check the access control list is very expensivein terms of CPU time.

[0008] There exists a need for an access check system that is moreefficient in its use of CPU time. Specifically, there exists a need foran access check system that performs the necessary access check, even atthe file-level of access control, without the relatively slow operationof opening the requested file-object to check the associated accesscontrol list.

STATEMENT OF THE SOLUTION

[0009] The above described problems and others are solved and an advancein the art is achieved by the access check system of the presentinvention. The methods of the present invention provide anaccess-permission caching system for storing the last most recentlygenerated access-permissions. If a request arrives at the server that issimilar, in terms of the requesting user and the requested resource, toa previously processed request, then the system of the present inventionlocates the previously generated access-permission in the access-cache.The requesting user's access-permission is therefore determined withoutopening the requested resource to read the associated access controllist. This capability is a significant savings of processing time whenrepetitive resource-requests arrive, such as internet requests for afile. An access check performed according to the methods of the presentinvention is easily made about 15% faster than an access check accordingto existing systems.

[0010] When a user “logs-on” to an operating system, the user supplies auser-name and password. If the operating system recognizes the user thena unique user-token is generated by the system and the user-token isadded to a user-token cache. At subsequent log-ons by the same user, thesystem returns the same user-token from the user-token cache. Then, ifthe user has requested a resource, the system checks the access-cache tosee if the requested resource has already been accessed by therequesting user. If the requested resource has already been accessed bythe requesting user then access to the resource is again provided by thesystem.

[0011] The access-cache contains access-permissions. Eachaccess-permission relates to a previously processed resource request andcontains the name of the requested resource and the user-name of theuser that requested the resource. In an embodiment of the presentinvention, the access-cache contains an access-permission for eachinstance of a resource that has been accessed. In a further embodimentof the present invention the access-cache contains an access-permissionfor only the most-recent instance that a resource has been accessed. Ifthe access-cache does not contain an access-permission containing theappropriate user-token and file-name, then a full access check isperformed as described above with respect to existing access checksystems. If upon performing the full access check it is determined thatthe requesting user has permission to access the requested resource, thesystem combines the name of the requested resource with the user-tokenof the requesting user into an access-permission and stores theaccess-permission in the access-cache. When this resource is specifiedin subsequent requests by the same user, the system will locate therelevant matching access-permission in the access-cache and return thematching access-permission to the server thereby indicating a positiveresult for the access check. The server then makes available to the userthe requested resource.

[0012] When a user-token is removed from the user-token cache, theaccess-cache is scanned for all access-permissions containing thesubject user-token and all occurrences are removed from the accesscache. When a resource is changed, all access-permissions in theaccess-cache associated with the subject resource are removed from theaccess-cache.

[0013] An area of significant advantage for the present invention ishandling file requests from anonymous users. In an internet serverapplication, for example, the vast majority of file-object requests arefrom anonymous users. According to the present invention, all anonymoususers share the same user-token and as a result the number of full,file-open access checks performed is dramatically reduced. The system ofthe present invention can also be configured to utilize filters to grouptogether users having similar access privileges thereby reducing thenumber of file-open access checks. Operation of the system of thepresent invention reduces the frequency of the file-open operationthereby reducing the CPU time necessary to perform access checks. Theoperating system is therefore able to run more efficiently and quickly.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 illustrates a network-computing environment in blockdiagram form.

[0015]FIG. 2 depicts a user-token cache memory location according to thepresent invention.

[0016]FIG. 3 depicts a file-object and associated access control list.

[0017]FIG. 4 depicts an access-control list according to the presentinvention.

[0018] FIGS. 5-6 illustrate access checking according to the presentinvention in flow diagram form.

DETAILED DESCRIPTION

[0019] General Network Computing Environment—FIG. 1

[0020]FIG. 1 illustrates a block diagram of server 100 connected overlocal bus 101 to network 102. Network 102 may be a local-area network orany other network where multiple users are able to access resources on asingle server, such as the internet. Connected to network 102 areclients 1-N. Client N represents any number of additional clientsconnected to the network. Server 100 communicates with other servers(not shown) and clients 1-N using a standard communications protocol.Programmed instructions for the access check system of the presentinvention are executable on processor 103. Processor 103 stores and/orretrieves the programmed instructions and/or data from memory devicesthat include, but are not limited to, Random Access Memory (RAM) 104 andRead Only Memory (ROM) 105 by way of memory bus 106. Another accessiblememory device includes non-volatile memory device 107 by way of localbus 101. Programmed instructions for implementing the access checksystem of the present invention are stored on non-volatile memory device107 as part of system application 108. Also stored on non-volatilememory 107 is file storage volume 109 containing various files asdiscussed below. The access check system of the present invention isoperable in any of several standard computing operating systems readilyavailable in the industry.

[0021] Assignment of User-Tokens—FIG. 2

[0022] A multiplicity of users (not shown) may connect to server 100through each of clients 1-N. The process by which a user connects toserver 100 is called “logging on”. When a user logs on to server 100,the user supplies a user-name and a password to server 100. If theuser-name and password supplied by the user are recognized by server 100then the user is allowed to log on, or connect, to server 100. In asystem where access-permission is required for a user to accessresources on a server, such as is the subject of the present invention,logging on to the server only allows a user to then request access to aresource on the server. Checking whether a user has access-permission toa particular resource, and providing access to the resource, is thesubject of the remaining discussion.

[0023] If a user logs on to server 100 for the first time, the system ofthe present invention assigns a unique user-token to the user and storesthe user-token in user-token cache 200. User-token cache 200, stored onRAM 104 of server 100 or on another suitable storage device, iscomprised of entries 201-203. There is an entry 201-203 for each userthat has logged on to server 100. Each entry 201-203 in user-token cache200 is comprised of a user-name 204, a user-token 205 and auser-password 206.

[0024] For example, when User 1 first logs on to server 100, server 100assigns a unique user-token, Token1, to User 1 and stores User 1'suser-name, user-password, and user-token as entry 201 in user-tokencache 200. When User 1 subsequently logs on to server 100, the system ofthe present invention retrieves User 1's user-token from user-tokencache 200 so that User 1 will be assigned the same user-token each timeUser 1 logs on to server 100.

[0025] In a network such as the internet, a large portion of the userslogging on to server 100 do so as an ‘anonymous’ user. Administratorsand certain other users may have unique user names and passwords but thebulk of the users logging on are doing so to access resources madeavailable to anonymous users on server 100. If no user-name and passwordis supplied by a user, server 100 assigns the user-name “Anonymous” tothe user. As a result, each anonymous user, one not supplying a usernameand password upon logging on, is assigned the same user-token by thesystem of the present invention. In the example of FIG. 2, and thefollowing figures, anonymous users are assigned user-token Token3. Entry203 is the entry for user Anonymous in user-token cache 200.

[0026] User-tokens 205 are represented in textual form to simplify thedescription of the present invention. In a preferred embodiment of thepresent invention, each user-token is a unique 32 bit value assigned bythe system of the present invention.

[0027] Access-Control Lists—FIG. 3

[0028] In a preferred embodiment of the present invention the control ofaccess to server 100's resources is at the file level. This means thateach file-object stored on server 100 has associated with it adefinition, called an Access Control List (ACL), of which users havewhat access rights with respect to the particular file-object.

[0029] Non-volatile memory 107 contains file-storage volume 109.File-storage volume 109 contains a number of file-objects 300-302 ofwhich file-object 300 of FIG. 3 is exemplary. File-objects 301-302,discussed with respect to FIG. 4 along with file-object 300, are notshown in the figures but are of the same format as described below withrespect to file-object 300.

[0030] File-object 300 is comprised of ACL 301 and file 302. File 302 isthe actual, substantive content of file-object 300. ACL 301 defines theextent to which various users can access and manipulate file 302. ACL301 of file-object 300 contains Access Control Entries (ACE) 305-307.Each ACE 305-307 is comprised of a user-token field 303 and apermitted-access field 304. ACE 305 defines the permitted access to file302 by the user having user-token token1. The permitted access 304 forToken1 is “Full Control” meaning user 1 can manipulate file 302 in anyway possible through the operation of server 100. Likewise, the user towhich Token2 is assigned as a user-token has “read/write” permission forfile-object 300. Users logged in as Anonymous and assigned Token3 as auser-token are permitted only read access according to ACE 307 of accesscontrol list 301. Although only three ACE's are depicted in accesscontrol list 301 of FIG. 3, those skilled in the art will recognize thatany number of ACE's could be added to access control list 301 asnecessary for the needs of server 100.

[0031] Although the example of file-object 300 depicts access control atthe file level of server 100, those skilled in the art will readilyrecognize that the methods of the present invention readily apply tosystems having different levels of access control. For example, inserver 100 an access control list could be associated with non-volatilememory 107 so that access to all resources on non-volatile memory 107would be defined by a single access control list. Another example wouldbe an access control list associated with file-storage volume 109whereby access to all the files stored in file-storage volume 109 wouldbe defined by a single access control list. It is also within the scopeof the present invention to utilize access control list's at differentlevels within the same server 100 so, for example, there could be anaccess control list associated with non-volatile memory 107 and separateaccess control list's associated with some or all of the file-objectsstored on non-volatile memory 107.

[0032] Access-Cache—FIG. 4

[0033] Access-cache 400 of FIG. 4 is comprised of access-permissions403-407 each of which is comprised of a filename field 401 and auser-token field 402. Each access-permission 403-407 indicates that auser, identified by the user-token in user-token field 402, haspermission to access, and has accessed, the file identified in thecorresponding file-name field 401. Each time server 100 performs anaccess check for a user-token/file name combination not already existingas an access-permission in access-cache 400 for which access ispermitted, server 100 enters a new access-permission in access cache400.

[0034] In a further embodiment of the present invention, access-cache400 only contains an access-permission for the most recent instance of afile having been accessed.

[0035] For example, FIG. 4 indicates two access permissions 403 and 405for file name 300. If access-permission 403 is the more recent of thetwo then it would have overwritten access-permission 405 and there wouldbe only a single access-permission for file 300 in access-cache 400.This approach is simpler to implement than the embodiment creating anaccess-permission each time a new user-token accesses a given file. Thesame advantages are achieved, however, especially when there are fewusers or a common user such as the anonymous user of the internetexample.

[0036] Access Check System: General Operation—FIGS. 1-4

[0037] In general, when a user requests access to a file-object onnon-volatile memory 107, server 100 first checks access-cache 400 todetermine if there is an access-permission 401 that matches both theuser-token for the requesting user and the requested file. If there is amatching access-permission in access-cache 400, the existence of whichindicates that the necessary access check has already been performed,access to the requested file is granted. If there is no matchingaccess-permission in access-cache 400, server 100 performs a full accesscheck by opening the requested file and reading the access control listassociated with the requested file. If, as a result of the access check,access is permitted, then a corresponding access-permission is appendedto access-cache 400.

[0038] An example of User 1 requesting file-object 300 is described withrespect to FIGS. 1-4. User 1, as one of clients 1-N, attempts to log onto server 100 by supplying a user-name and a password to server 100 overnetwork 102. The user-name and password supplied by User 1 arerecognized by server 100 and User 1 is therefore allowed to log on toServer 100. Server 100 first checks user-token cache 200 of FIG. 2 for auser-token matching User 1's user-name and password. Entry 201 ofuser-token cache 200 matches User 1's user-name and therefore server 100retrieves Token1 from user-token cache 200 to use as the user-token forUser 1.

[0039] User 1 requests to read file 300. Server 100 checks access-cache400 for an access-permission matching the current request.Access-permission 403 relates to file-object 300 but the user-token foraccess-permission 403 doesn't match User 1's user-token.Access-permission 405 is comprised of a file-name field containing thename of the requested file and a user-token field containing User 1'suser-token. Access-permission 405 is therefore returned by the system toserver 100 signifying that User 1 has been granted permission to readfile-object 300. Server 100 then allows access to file 300 by User 1.

[0040] A further example of the general operation of the methods of thepresent invention is described with respect to User 2 requesting to readfile-object 300. User 2, as one of clients 1-N, attempts to log ontoserver 100 by supplying a user-name and a password to server 100 overnetwork 102. The user-name and password supplied by User 2 arerecognized by Server 100 and User 2 is therefore allowed to log on toServer 100. Server 100 first checks user-token cache 200 of FIG. 2 for auser-token matching User 2's user-name. Entry 202 of user-token cache200 matches User 2's user-name and therefore server 100 retrieves Token2from user-token cache 200 as the user-token for User 2.

[0041] User 2, now logged on to server 100, places a request to readfile-object 300. Server 100 checks access-cache 400 for anaccess-permission matching the current request. Access-permissions 403and 405 each have file-object 300 in the file-name field 401 but neitheraccess-permission 403 or 405 have a user-token field 402 that matchesUser 2's user-token. This means that User 2 has not previously read file300 and the system must perform a full, file open, access check.Referring to FIG. 3, file-object 300 is opened and access control list301 is read to determine the access-permission granted to User 2. ACE306 defines User 2's granted access to file-object 300. Permitted-accessfield 304 of ACE 306 indicates that User 2 has read/write permission forfile 300. Access for reading file-object 300 is therefore provided toUser 2. Once the file-open access check is completed, an appropriateaccess-permission (not shown) is added to access-cache 400 so that afile-open access check will not need to be performed the next time User2 requests file-object 300.

[0042] In the above examples of an embodiment of the present invention,access-permissions are only generated and utilized with respect to Readaccess requests. In a further embodiment of the present invention,access-cache 400 also includes information about the level of accessassociated with a previous resource request. In this embodiment, if auser having a certain user-token has previously read a certain file butis currently asking to write the file, a new access-permissionreflecting the write permission is generated, if appropriate, and addedto the access-cache.

[0043] Access Check System: Security Maintenance—FIGS. 2-4

[0044] When changes are made to a file-object, the methods of thepresent invention operate to ensure that access-cache 400 is updated sothat unintended security holes are avoided. Likewise, if user-tokencache 200 is modified, the methods of the present invention operate toensure that access-cache 400 is updated appropriately.

[0045] When a file-object is modified, the system of the presentinvention flushes all access-permissions in access-cache 400 containingthe file name of the modified file-object. This means that on the nextrequest for the file-object, the system will be required to perform afull access check by opening the requested file-object to read theassociated access control list thereby ensuring that any changes made tothe access control list are not over-looked. Maintaining the security ofthe system in such a way is necessary or access-cache 400 couldeffectively circumvent any changes made to the access control lists.

[0046] In a further embodiment of the present invention, access-cache400 is flushed of all occurrences of the file name of the modifiedfile-object only when it is the access control list of the file-objectthat has been modified. Otherwise, if changes have been made to thefile-object that do not effect the access control list then thecorresponding entries in access-cache 400 are left untouched.

[0047] If a user's access to the resources of server 100 is modified oreliminated, then the corresponding entry in the user-token cache isremoved. When a user-token is removed from user-token cache 200, thesystem of the present invention flushes all access-permissions inaccess-cache 400 containing the removed user-token. This eliminates thepossibility of access-cache 400 allowing access to resources even aftera user's access to server 100 has been modified or eliminated.

[0048] Access Check System: Efficiency Optimization—FIGS. 2-4

[0049] An advantage of the present invention for access checks is theelimination of the need to open access control lists each time aresource request is processed if a similar request has already beenprocessed. A way to maximize this advantage is to group or cluster usersto reduce the number of different user-tokens. For example, a number ofusers within the same work-group might all be granted the same level ofaccess to the files on server 100. A filter can be applied by the systemof the present invention so that when a member of the group logs on toserver 100, they are assigned the user-token designated for that grouprather than a user-token unique to the individual user. In this fashion,fewer user-tokens are generated and therefore fewer access checksrequiring the reading of access control lists are performed.

[0050] A variation of this advantage is to operate the system of thepresent invention so that a group or class of users log on to server 100using the same user-name and password and as a result are assigned thesame user-token upon logging on. For example, user-name “Anonymous” isassigned to user's placing requests over the internet for resources onserver 100. All such users are assigned the same user-token, Token3 inthe example of FIGS. 2-4, and the number of access checks performed byserver 100 is significantly reduced. Another example is a server thatmaps each user that logs on to one of several different user names. Eachuser name to which a logged-on user is mapped might correspond to aworkgroup, a level of security access, or any other grouping deemedappropriate by the system administrator.

[0051] Access Check System: Detailed Operation—FIG. 5

[0052] The flow-charts of FIGS. 5-6 depict the operation of the methodsof the present invention in greater detail. FIG. 5 depicts the operationof the access-cache system while FIG. 6 depicts the operational steps ofthe security maintenance features of the present invention.

[0053] Step 500 represents the process of a user logging on to server100. As described above with respect to FIG. 2, a user optionallysupplies a user-name and a password and is allowed to log on to server100 if server 100 recognizes the user-name and password. Once a user haslogged on, processing continues to decision block 502.

[0054] Decision block 502 operates to determine if the user-name of theuser exists in an entry in user-token cache 200. If the relevantuser-name exists in user-token cache 200 then processing continues tostep 504, otherwise processing continues to step 508. Step 504 operatesto retrieve from user-token cache 200 the user-token associated with therelevant user-name. All file requests by the user are then identified byserver 100 with the user-token retrieved from user-token cache 200.

[0055] Step 508 operates to generate a unique user-token for the userif, in decision block 502, it was determined that a user-token had notyet been assigned to the user.

[0056] Then, in step 510, the generated user-token is appended touser-token cache 200 so that the next time the user logs on to server100, the assigned user-token will be available in user-token cache 200.After both step 504 and step 510 processing continues with decisionblock 506.

[0057] Decision block 506 operates to determine if access-cache 400contains an access-permission that matches the request made by the user.As noted above, a matching access-permission is one that contains therelevant user-token and the requested file-name. If a matchingaccess-permission is identified in access-cache 400 then processingcontinues to step 512 otherwise processing continues to step 516.

[0058] Step 512 operates to retrieve the matching access-permission fromaccess-cache 400. Server 100 then, in step 514, provides access to therequested file as requested by the user. In step 516, since a matchingaccess-permission was not found in access-cache 400, a full access checkis begun by opening the requested file-object and reading the associatedaccess control list. Processing then continues to decision block 518.

[0059] Decision block 518 operates to determine if the access controllist of the requested file-object permits the access requested by theuser. If the user is permitted the requested access according to theaccess control list then processing continues with step 520 otherwiseprocessing continues to step 522. During step 520, a newaccess-permission is generated for the current user and requested fileand the new access-permission is appended to the contents ofaccess-cache 400. Processing then continues to step 514 where the useris provided access to the requested file.

[0060] If, in decision block 18, it is determined that the user does nothave the requested access-permission, then processing continues to step522. In step 522 an error message is generated and communicated to theuser to notify the user of the negative result of the access check.After a file request has been processed, either concluding withproviding the requested access as in step 514 or by notifying the userof the user's lack of access as in step 522, processing continues tostep 524.

[0061] Decision block 524 operates to determine if there are additionalfile requests by the user that have not been processed. For example, inthe case of server 100 operating as an internet server, it oftenreceives multiple file requests at once from a single user. Each ofthese file requests is processed in the same fashion as described above.If the operation of decision block 524 determines that there are furtherfile requests by the same user to be processed then processing returnsto decision block 506 otherwise processing continues to step 526 whereprocessing of the user's file requests is concluded.

[0062] Access Check System: Detailed Operation—FIG. 6

[0063] The processing steps 600-606 depicted in FIG. 6 are repeated on aregular, periodic basis to ensure the security of the resources ofserver 100. Decision block 600 operates to determine if a file-objecthas been modified. If a file-object has been modified, processingcontinues to step 602 otherwise processing continues to step 604.

[0064] In step 602, access-cache 400 is flushed of allaccess-permissions containing the file-name of the modified file. Thisoperation ensures that any changes to a file's access control list willnot be over-looked as a result of the operation of the access checksystem of the present invention. Processing then continues to decisionblock 604.

[0065] Decision block 604 operates to determine if a user-token has beendeleted from the user-token cache. If a user's level of access to server100 is modified or eliminated, the user-token associated with the useris removed from the user-token cache by the operation of server 100.This occurrence is identified by the operation of decision block 604 andprocessing accordingly proceeds to step 606. In step 606, access-cache400 is flushed of all access-permissions containing the deleteduser-token. Processing then continues to decision block 600 where thesecurity steps of 600-606 are again initiated.

[0066] Steps 600-606 ensure that the speed and efficiency advantages ofthe access check system of the present invention do not result insecurity holes. The increased speed of the present invention is therebyimplemented only when, from a security standpoint, it is safe to do so.

SUMMARY

[0067] The access check system of the present invention includes amethod and apparatus for efficiently accomplishing access checks forrequested resources rather than performing a full, file-open, accesscheck each time a user requests a resource. Although specificembodiments are disclosed herein, it is expected that persons skilled inthe art can and will design alternative header generation systems thatare within the scope of the following claims either literally or underthe Doctrine of Equivalents.

We claim:
 1. A computer-readable medium having computer-executableinstructions for providing access to a computer network by performingsteps comprising: receiving a request from a user to access a resourceon the computer network; checking a first memory to determine if theuser may access the resource; providing the user with access to theresource if the first memory indicates that the user may access theresource; checking a second memory to determine if the user may accessthe resource if the first memory does not indicate that the user mayaccess the resource; providing the user with access to the resource ifthe second memory indicates that the user may access the resource; andstoring information in the first memory indicating that the user mayaccess the resource if, after checking the second memory, the secondmemory indicates that the user may access the resource.
 2. Thecomputer-readable medium of claim 1 wherein the first memory indicatesthat the user may access the resource by indicating that access to theresource has been previously provided to the user.
 3. Thecomputer-readable medium of claim 1 wherein the user is represented inthe first memory by a token.
 4. The computer-readable medium of claim 3wherein the token also represents a plurality of other users.
 5. Thecomputer-readable medium of claim 3 wherein the token representsanonymous users.
 6. The computer-readable medium of claim 3 furthercomprising: authorizing fs to check the first memory.
 7. Thecomputer-readable medium of claim 1 wherein the resource is a file. 8.The computer-readable medium of claim 1 wherein the resource is a volumeof files.
 9. The computer-readable medium of claim 1 wherein theresource is a memory device.
 10. The computer-readable medium of claim 1wherein storing the information in the first memory comprisesoverwriting other information associated with the resource in the firstmemory.
 11. The computer-readable medium of claim 10 wherein storing theinformation in the first memory comprises writing a token for the userin the first memory over another token for another user that had lastprevious access to the resource.
 12. The computer-readable medium ofclaim 1 further comprising, if the resource is altered, removingindications from the first memory allowing access to the resource. 13.The computer-readable medium of claim 1 further comprising, if rights ofthe user are altered, removing indications from the first memoryallowing access by the user.
 14. The computer-readable medium of claim 1wherein the request from the user indicates an operation to perform withrespect to the resource, and further comprising: checking the firstmemory to determine if the user may perform the operation with respectto the resource; providing the user with access to the resource toperform the operation if the first memory indicates that the user mayperform the operation with respect to the resource; checking a secondmemory to determine if the user may perform the operation with respectto the resource if the first memory does not indicate that the user mayperform the operation with respect to the resource; providing the userwith access to the resource if the second memory indicates that the usermay perform the operation with respect to the resource; and storinginformation in the first memory indicating that the user may perform theoperation with respect to the resource if, after checking the secondmemory, the second memory indicates that the user may perform theoperation with respect to the resource.
 15. A method for providingaccess to a computer network, the method comprising: receiving a requestfrom a user to access a resource on the computer network; checking afirst memory to determine if the user may access the resource; providingthe user with access to the resource if the first memory indicates thatthe user may access the resource; checking a second memory to determineif the user may access the resource if the first memory does notindicate that the user may access the resource; providing the user withaccess to the resource if the second memory indicates that the user mayaccess the resource; and storing information in the first memoryindicating that the user may access the resource if, after checking thesecond memory, the second memory indicates that the user may access theresource.
 16. The method of claim 15 wherein the first memory indicatesthat the user may access the resource by indicating that access to theresource has been previously provided to the user.
 17. The method ofclaim 15 wherein the user is represented in the first memory by a token.18. The method of claim 17 wherein the token also represents a pluralityof other users.
 19. The method of claim 17 wherein the token representsanonymous users.
 20. The method of claim 17 further comprising:authorizing the user by checking a password provided by the user;associating the token with the user after authorizing the user; andusing the token to check the first memory.
 21. The method of claim 15wherein the resource is a file.
 22. The method of claim 15 wherein theresource is a volume of files.
 23. The method of claim 15 wherein theresource is a memory device.
 24. The method of claim 15 wherein storingthe information in the first memory comprises overwriting otherinformation associated with the resource in the first memory.
 25. Themethod of claim 24 wherein storing the information in the first memorycomprises writing a token for the user in the first memory over anothertoken for another user that had last previous access to the resource.26. The method of claim 15 further comprising, if the resource isaltered, removing indications from the first memory allowing access tothe resource.
 27. The method of claim 15 further comprising, if rightsof the user are altered, removing indications from the first memoryallowing access by the user.
 28. The method of claim 15 wherein therequest from the user indicates an operation to perform with respect tothe resource, and further comprising: checking the first memory todetermine if the user may perform the operation with respect to theresource; providing the user with access to the resource to perform theoperation if the first memory indicates that the user may perform theoperation with respect to the resource; checking a second memory todetermine if the user may perform the operation with respect to theresource if the first memory does not indicate that the user may performthe operation with respect to the resource; providing the user withaccess to the resource if the second memory indicates that the user mayperform the operation with respect to the resource; and storinginformation in the first memory indicating that the user may perform theoperation with respect to the resource if, after checking the secondmemory, the second memory indicates that the user may perform theoperation with respect to the resource.